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Abstract 

Networks  are  becoming  a  part  of  everyday  life.  They  are  in  our  offices,  homes,  cars,  and 
the  basis  for  the  Internet.  The  ground  processing  side  of  T&E  have  used  networks  in 
various  forms  for  years  to  direct  the  incoming  test  data  to  the  many  project  engineer 
stations.  These  interfaces  are  becoming  relatively  inexpensive  due  to  the  proliferation  of 
networks.  We  are  now  seeing  networks  appear  in  the  vehicular  data  acquisition  arena. 

To  take  advantage  of  what  networks  have  to  offer,  we  need  to  view  the  data  system  as  a 
communications  network. 

As  a  communications  network,  the  instrumentation  system  must  be  segregated  into 
individual  layers  in  a  logical  fashion.  Each  layer  operates  independently  and  can  be 
upgraded  or  replaced  without  regard  or  effect  to  the  other  layers.  This  layered  model  can 
be  used  as  a  blueprint  to  take  advantage  of  commercial  network  architectures.  It  will 
easily  allow  new  technology  insertion  in  key  areas  without  affecting  the  rest  of  the 
system.  The  Navy  and  the  Air  Force  see  this  approach  as  a  key  component  of  acquisition 
reform  and  have  established  a  comprehensive  road  map  to  achieve  this  goal. 
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Background 

There  have  been  two  major  paradigm  shifts  involving  the  design  of  instrumentation 
systems  over  the  last  30  years.  The  first  shift  was  concerned  with  how  the  data  was 
multiplexed  for  acquisition.  The  early  instrumentation  systems  multiplexed  parameters 
within  the  frequency  domain  -  frequency  division  multiplexing  (PDM).  FDM  channels 
provide  fairly  fixed  bandwidths  per  channel  limiting  the  number  of  parameters  that  could 
be  multiplexed  at  one  time.  Most  current  systems  use  time  division  multiplexing  (TDM). 
TDM  uses  the  time  domain  to  multiplex  parameters  into  a  single  data  stream.  TDM 
allows  more  parameters  to  be  recorded  and/or  transmitted  by  allowing  more  flexibility  in 
assigning  bandwidth  per  channel.  For  many  systems  with  large  numbers  of  low 
frequency  parameters,  this  was  a  real  advantage.  Although  not  a  function  of  TDM,  the 
introduction  of  digital  technology  is  usually  associated  within  this  timeframe.  Since 
FDM  is  straight  forward  and  easy  to  use  in  small  systems,  it  has  not  died  out  completely 
(reference  figure  1). 


Figure  1  Evolution  of  Data  Systems 


The  next  major  shift  distributed  the  signal  conditioning  and  modulation  closer  to  the 
signal  source,  (reference  Figures  2  and  3)  A  distributed  system  was  easier  to  install  in 
space  constrained  test  articles  by  wiring  signal  sources  to  a  relatively  close  remote  unit. 
The  remote  unit  communicated  back  to  the  system  controller  via  a  communications  bus. 
The  controller  to  remote  unit  communication  introduced  a  higher  level  of  complexity 
than  was  seen  with  previous  systems.  As  distributed  systems  became  more  prevalent, 
system  designers  wanted  a  unit  from  one  system  to  work  within  another  system.  The 
Common  Airborne  Instrumentation  System  (CAIS)  set  out  to  fix  that  problem  by 
establishing  a  common  hardware  set  that  would  be  built  by  multiple  manufacturers. 
During  execution  of  the  CAIS  program,  acquisition  reform  resulted  discarding  the  build 
to  print  technical  data  package  in  favor  of  a  CAIS  Bus  Interface  Control  Document 
(ICD).  The  CAIS  Bus  ICD  was  a  solid  step  towards  one  of  the  primary  goals  of  the 
CAIS  program  -  vendor  interoperability. 
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Figure  2  Centralized  Data  System 
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Figure  3  Distributed  Data  System 

As  the  CAIS  Bus  ICD  was  completed,  a  couple  of  major  acquisition  programs  had 
instrumentation  requirements  that  exceeded  the  capacity  of  the  CAIS  system.  Looking  at 
the  data  system  capacity  of  one  program  over  a  number  of  years  shows  an  exponential 
requirement  (reference  Figure  4).  Projecting  this  growth  rate  to  the  near  future  shows  a 
need  for  a  high  capacity  data  bus.  The  Next  Generation  Instrumentation  Bus 
(NexGenBus)  was  started  to  help  meet  this  need.  An  unexpected  outcome  of  the 
NexGenBus  research  of  fast  commercial  communications  busses  showed  them  all  to  be 
network  compatible.  The  Advanced  Range  Telemetry  (ARTM)  program  looked  at 
alternate  telemetry  methods  and  discovered  that  packetized  telemetry  was  a  viable 


alternative  to  the  way  we  currently  do  business.  By  many  accounts,  we  are  now  on  the 
verge  of  a  third  technology  shift  -  Data  Acquisition  Networks. 
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Data  Acquisition  Networks 

The  Next  Generation  Instrumentation  Bus  (NexGenBus)  program  was  established  to  find 
a  fast  commercial  communications  bus  that  could  be  used  as  a  test  instrumentation  bus. 
When  the  list  of  fast  commercial  busses  was  compiled,  it  was  discovered  that  all  of  the 
busses  were  networked  based.  This  realization  was  a  source  of  both  concern  and  delight. 
The  concern  was  the  complexity  of  the  bus  and  the  systems  that  would  communicate 
across  it.  Traditionally,  test  article  instrumentation  has  been  tightly  coupled  application 
specific  designs.  Instrumentation  engineers  learned  how  to  design  an  installation  based 
on  one  of  a  few  systems.  The  broad  application  of  network  based  systems  represents  a 
huge  learning  curve  to  the  vast  majority  of  users.  At  the  same  time,  there  is  a  feeling  of 
delight.  We  have  all  used  email  and  the  Internet  at  one  time  or  another.  Enabling  the  test 
instrumentation  with  similar  connectivity  across  the  test  range  and  throughout  the  country 
was  attractive.  The  ability  to  connect  the  test  article  (e.g.  an  aircraft  on  the  flight  line)  on 
one  side  of  the  test  range  to  the  network  and  trouble-shoot  or  verify  software  loads  from 
the  other  side  is  just  the  tip  of  what  network  connectivity  will  bring. 

Layered  Models 

While  researching  busses  during  the  NexGenBus  project,  the  one  thing  found  to  be 
common  among  the  different  standards  was  a  layered  communication  model. 
Unfortunately  they  did  not  all  use  the  same  model,  but  the  individual  models  use  the 
same  basic  model  as  a  starting  point.  It  is  not  important  to  understand  each  of  these 
individual  models.  It  is  important  to  understand  a  basic  reference  model.  The  basic 
reference  model  that  is  most  notable  is  the  Open  System  Interconnection  (OSI)  Basic 
Reference  Model  (also  called  the  7  layer  communications  model).  There  two  major 
reasons  the  OSI  model  should  be  considered.  First,  it  teaches  the  concept  of 
independence  of  layers.  Second,  even  though  it  is  hardly  ever  called  out  directly  in  a 
standard  or  communication  system,  it  is  the  standard  to  which  others  are  compared  and 
discussed. 


There  are  7  layers  in  the  OSI  model.  The  top  or  1^  layer  is  closest  to  the  user  and 
application  software  that  resides  on  your  PC  (e.g.  MS  Word).  The  lowest  or  layer  is 
the  actual  physical  cable  or  RF  signal  that  moves  the  data  from  one  node  to  another.  The 
layers  between  the  top  and  the  bottom  are  intermediate  steps  the  system  takes  to  ensure 
the  data  gets  where  it’s  supposed  to  go.  What  makes  the  OSI  model  so  useful  is  that  each 
layer  is  independent  of  the  other  layers.  The  model  was  created  such  that  the  interfaces 
are  standardized  so  a  layer  can  be  changed  without  significantly  affecting  the  rest  of  the 
stack.  The  OSI  layers  as  defined  in  the  ISO  standard  are  listed  below. 


Layer  7: 

APPLICATION 

The  highest  layer  in  the  OSI  reference  model.  This  layer  provides  the 
sole  means  for  an  application  process  to  access  the  OSI  environment. 

Layer  6: 

PRESENTATION 

The  Presentation  Layer  provides  for  common  representation  of  the  data 
transferred  between  application-entities. 

Layer  5: 

SESSION 

The  Session  Layer  provides  the  means  necessary  for  cooperating 
presentation-entities  to  organize  and  synchronize  their  dialogue  and  to 
manage  their  data  exchange. 

Layer  4: 

TRANSPORT 

The  transport-service  provides  transparent  transfer  of  data  between 
session  entities  and  relieves  them  from  any  concern  of  the  details  of  the 
data  transfer. 

Layer  3: 

NETWORK 

The  Network  Layer  provides  the  functional  and  procedural  means  for 
transmission  among  transport-entities.  It  therefore  relieves  the  transport- 
entities  of  routing  and  relay  considerations. 

Layer  2: 

DATA  LINK 

The  Data  Link  Layer  provides  the  functional  and  procedural  means  for 
the  establishment,  maintenance,  and  release  of  data  link  connections. 

The  Data  Link  Layer  detects  and  possibly  corrects  errors  which  may 
occur  in  the  Physical  Layer. 

Layer  1 : 

PHYSICAL 

The  Physical  Layer  provides  the  mechanical,  electrical,  functional  and 
procedural  means  to  activate,  maintain,  and  de-activate  physical 
connections  for  bit  transmission  between  data-link-entities. 

Information  being  transferred  from  a  software  application  in  one  computer  system  to  a 
software  application  in  another  must  pass  through  each  of  the  OSI  layers.  To  send  a 
sound  file  from  one  computer  to  another,  the  user  directs  the  software  to  send  the  file. 

The  file  is  passed  to  the  Application  Layer  that  may  add  control  information  to  the  file 
and  pass  it  to  the  Presentation  Layer.  The  Presentation  Layer  treats  the  original  file  plus 
the  Application  Layer  control  information  as  data.  Each  layer  will  perform  work  on  the 
data  being  passed  from  the  previous  layer  according  to  its  protocol.  Once  down  at  the 
Physical  Layer,  the  information  is  placed  on  the  physical  network  medium  and  sent  to  the 
other  computer.  The  Physical  Layer  of  the  second  computer  removes  the  data  from  the 
physical  medium  and  passes  the  data  up  the  stack  to  the  next  layer.  This  continues  until 
the  Application  Layer  passes  the  data  to  the  application  software  where  the  user  can 
access  the  sound  file. 

The  real  power  of  this  can  be  seen  in  an  office  environment.  When  the  local  area 
network  (LAN)  is  upgraded  from  Ethernet  (10  Mbps)  to  Fast  Ethernet  (100  Mbps),  only 
the  lowest  level  needs  to  be  changed— the  transmitter  and  receiver  circuitry  as  well  as  the 
actual  cable  and  connectors.  The  rest  of  the  communication  stack  can  be  left  as  is.  The 
user  may  notice  the  faster  transfer  rate  but  his  or  her  interface  stayed  the  same.  In  reality. 


things  aren’t  necessarily  this  clean  but  it  does  illustrate  the  point.  Another  power  of  this 
concept  is  the  ability  to  link  dissimilar  networks  through  bridges  and  routers  (reference 
figure  5)  or  to  intermix  physical  media  within  the  same  network. 
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Figure  5  Networks  connected  across  a  router 


A  Layered  Approach 

There  are  two  things  that  can  be  assured  within  the  framework  of  this  paper.  One  is  the 
Department  of  Defense  no  longer  drives  the  data  acquisition  market.  The  other  is  we  are 
living  in  a  networked  world.  As  a  result  of  these  two  “truths”,  we  need  to  embrace  the 
network  revolution  and  do  so  in  a  way  that  is  compatible  to  the  commercial  network 
market.  This  is  not  to  say  we  should  start  blindly  flying  laptops  with  data  acquisition 
cards  and  wireless  Ethernet  connections.  What  this  does  mean  is  we  need  to  choose  our 
“fights”  carefully.  One  of  the  first  steps  we  must  take  towards  embracing  the  commercial 
network  world  is  to  adopt  their  lexicon.  The  telemetry  community  is  no  longer  isolated 
from  other  markets  due  to  writing  their  own  specifications.  There  are  several  examples 
where  the  telemetry  community  is  adopting/adapting  commercial  standards  in  part  or  in 
whole.  Without  using  a  common  dictionary  from  the  beginning,  the  resultant  standards 
are  ambiguous  thus  not  useful. 

The  second  and  more  important  step  is  to  not  take  this  shift  to  networks  lightly.  If  we 
want  to  benefit  from  the  telecommunications  market,  we  must  structure  our  approach 
appropriately.  As  new  cables,  interfaces,  and  protocols  are  developed,  we  want  the 
choice  of  adopting  them  in  the  same  manner  as  any  network  administrator.  A  layered 
reference  model  is  needed  to  take  advantage  of  what  the  COTS  market  has  to  offer.  As 
usual,  it’s  not  quite  as  easy  as  it  seems.  Simply  adopting  a  reference  model  is  not 


enough.  We  need  a  reference  model  that  will  meet  our  needs  given  the  way  we  do 
business  now  and  the  way  we  want  to  do  business  in  the  future.  The  only  way  to  get  a 
model  that  meets  our  needs  is  to  develop  one.  The  only  way  to  develop  one  is  to 
understand  the  business  you  want  to  model  and  understand  how  to  construct  a  model. 
Many  in  the  Telemetry  community  have  solid  understandings  of  how  we  are  currently 
operating.  Some  of  the  Telemetry  community  have  strong  conceptions  of  how  we  can 
benefit  from  network  technology.  Few  in  the  Telemetry  community  know  how  to 
combine  our  understandings  and  conceptions  into  a  comprehensive  model  that  can  guide 
the  development  and  application  of  new  technology.  If  we  want  to  maximize  the  cost  and 
technology  benefits  of  the  Telecommunications  market,  we  need  to  start  putting  our 
energies  into  understanding  and  developing  a  layered  reference  model. 

What  we  are  doing  now 

There  has  been  a  lot  of  momentum  toward  the  idea  of  network  based  data  acquisition 
over  the  past  couple  of  years.  A  vocal  consensus  seems  to  have  been  reached  that 
networks  are  indeed  coming.  The  Range  Commanders  Council  (RCC)  has  several  tasks 
related  to  network  compatibility  of  which  some  are  funded  through  the  Office  of  the 
Secretary  of  Defense  (OSD).  These  tasks  and  projects  have  done  a  pretty  good  job  of 
spreading  the  word  about  network-based  initiatives.  Many  vendors  have  listened  and  are 
including  network  capable  products  in  their  brochures  and  demonstrations. 

Unfortunately  everyone  is  working  to  his  or  her  own  conceptions.  We  need  to 
communicate  a  common  model  so  everyone  will  be  driving  toward  the  same  solution. 


There  are  several  venues  where  network  issues  are  starting  to  be  addressed  -  especially  at 
a  systems  level.  The  Range  Commanders  Council  (RCC)  have  a  conceptual  idea  of  how 
network  connectivity  could  benefit  the  telemetry  market  (reference  figure  6).  This  is  far 
from  complete,  but  it  is  a  start.  Based  on  this  understanding  a  Networks  part  will  be 
added  to  the  IRIG  106  Telemetry  Standards.  The  Joint  Data  Acquisition  Networks 
Standard  (JDANS)  (a  proposed  OSD  program  to  begin  in  FY02),  is  planning  to  attack 
this  problem  in  detail.  To  help  precipitate  these  ideas,  a  joint  DoD/NASA  task  force  is 
being  put  together  to  leverage  knowledge  and  requirements  between  the  two  agencies. 
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Figure  6  Data  Acquisition  Network  Concept 
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